Method and arrangement for enabling communication with a client device

ABSTRACT

A method and arrangement for enabling communication with a client device by making a currently valid communication address of the device publicly available. The client device sends a freely composed connectivity key to a publicly available connectivity server, the connectivity key being searchable by means of web searching using a search engine. The client device also sends connectivity parameters to the connectivity server including at least the communication address, which then becomes publicly available in the connectivity server by web searching of the associated connectivity key. If a new currently valid communication address is obtained for the client device, the connectivity parameters can be updated by sending the new communication address to the connectivity server.

TECHNICAL FIELD

The present invention relates generally to a method and arrangement formaking a communication address, e.g. the IP (Internet Protocol) address,currently used by a client device easily available to any other person,device or application in order to enable communication.

BACKGROUND

The advent of Internet has created a vast industry for making all kindsof information and data available from servers to any user operating acommunication terminal equipped with a web browser. A server offeringinformation over the Internet can be accessed from any such clientdevice by entering a domain name in the web browser, which has beenregistered for that server. The domain name is then translated into acorresponding IP address serving as the network address of the server towhich messages and requests can be routed, as the domain name itselfcannot be used for routing. IP addressing is the generally used standardfor communication over the Internet.

Most likely, the Internet and the IP addressing will also be used to agreat extent in the future for packet-based communication betweenvarious client devices, sometimes referred to as “Peer-to-Peer”communication. A mechanism is then needed for making the currently usedIP address (or other applicable network address) of a client deviceeasily available to any person, device or application that might want tocommunicate with that particular client device over the Internet.

As indicated above, all client devices and servers must typically have aroutable IP address in order to be capable of communication with othersover the Internet. IP addresses are typically composed of numbersseparated by dots, e.g. 192.78.32.1, according to well-known structuresand rules which are not necessary to describe here in any detail tounderstand the present invention. IP addresses that are globally uniquecan be allocated to servers and different access networks all over theworld by a central administrator. Each access network operator can thenassign IP addresses to individual subscribers and client devices in thenetwork according to local rules and schemes.

With the emergence of 3G mobile telephony, new packet-basedcommunication technologies have been developed using IP addressing formobile terminals, including GPRS (General Packet Radio Service) andWCDMA (Wideband Code Division Multiple Access). When a mobile terminalconnects to such a packet-based mobile access network, a PDP (PacketData Protocol) context including certain communication parameters isestablished for the terminal so as to prepare for any upcoming session,which is a normal procedure in any packet-based mobile networks. The PDPcontext is always created by the home network of the mobile terminal,even if it is currently visiting another network.

Establishing a PDP context includes assigning a temporary IP address tothe mobile terminal which is stored together with a subscriber identity,e.g. MSISDN (Mobile Subscriber ISDN Number), in a session database.Typically, at least in WCDMA networks and GPRS networks, the GGSN(Gateway GPRS Support Node) creates the PDP context by fetching atemporary IP address from a DHCP (Dynamic Host Configuration Protocol)server assigning idle temporary IP addresses to active mobile terminals.The procedure of establishing a PDP context for a mobile terminal iswell-known and is not necessary to describe here further.

The terminal can then use its assigned temporary IP address forpacket-switched communication throughout its active period in the accessnetwork, until it is disconnected. When the terminal is connected onceagain, a new PDP context is established typically rendering a newtemporary IP address other than the previous one, and so forth. Thetemporary IP address may also be changed whenever the terminal movesfrom one mobile access network to another, or moves between differentregions within the same network using different sets of IP addresses,etc.

Other types of access networks use fixed access points to which anysubscriber can connect his/her client device, either wirelessly or usinga wire jack plug. In this case, the network operator may assign an IPaddress more or less permanently to such an access point, which is thenused for any client device that connects to that access point. In thistype of networks, subscribers can typically move their client devicesfreely between different access points.

Hence, it can be readily understood from the above that the IP addressfor a particular client device may be frequently changed, and it istherefore not feasible for a user to retain a contact list of IPaddresses for client devices as it becomes outdated in due course. Amechanism is therefore needed for keeping the currently used IP addressup to date and available for anyone (a person, device or application)wanting to reach the client device. Therefore, a domain name is commonlyused as an alias for whatever IP address is currently used forcommunication over the Internet. As mentioned above, the use of domainnames has been widely practiced for servers having permanent IPaddresses, but it can also be used for client devices. The conventionaluse of domain names in this context will be briefly outlined below.

A domain name can thus be registered with a domain name registrationauthority for a particular communication node (e.g. a host server orclient device), according to conventional procedures, as beingassociated with the IP address valid for that node. A domain namebasically comprises words or codes separated by dots, and may beincluded in a URL (Unified Resource Locator). An exemplary server domainname is www.ericsson.com. More personal domain names can also beregistered for client devices, e.g. based on a personal name such aswww.christoferflinta.se, or a telephone number such as www.070123456.se,etc.

The domain name can be entered in a web browser and is then translatedinto a corresponding IP address, in order to access the node using thatIP address and domain name combination. Each domain name is thusassociated with an IP address that has been assigned to thecorresponding node, as the domain name itself cannot be used directly asa network address but must be translated into one for routing.

Registrations of domain names are made in specific domain name serversthat are organized in a so-called “DNS (Domain Name Service) tree”structure, as is well-known in the art. Typically, a fixed host serveror the like has a permanent IP address and will therefore not requireany updating, but also end-users can register domain names for their PCstations or other devices, e.g. using temporary IP addresses. In thatcase, the association of a domain name with an IP address must beupdated with the registration authority each time the IP address ischanged.

FIG. 1 illustrates schematically how a DNS tree 100 is built logically,comprising a plurality of servers of which just a few are shown here. Ineffect, the DNS servers make up a distributed hierarchically structureddatabase containing registered domain names and their associated IPaddresses, where each level in the tree corresponds to a word positionin a domain name, as separated by the dots therein.

The top level 102 of the tree 100 has a singular root server, and thenext level 104 contains a number of servers representing a word afterthe last dot in a domain name, e.g. “.com” and “.se” as illustrated,which may be a generic code or a country code. The next level 106contains a number of so-called “top level domain” servers representingthe next word in a domain name, e.g. “x.se”, “y.se”, “z.se” asillustrated, and so forth. In this example, the server representing thedomain name “z.se” covers a set 108 of complete domain names and theircorresponding IP addresses, although in reality, the DNS tree includesmany more possible levels.

Briefly described, a “requester” 110 (in the figure representing, e.g.,a PC or a mobile telephone equipped with a web browser) intends to senda message directed to a specific domain name that a user has entered inthe web browser, without initially knowing which IP address it isassociated with. In order to send the message, the associated IP addressmust be found if unknown. To obtain the IP address, the domain name isfirst transferred to a “resolver” entity 112, in a first step 1:1. Theresolver 112 is adapted to access the DNS tree at different levels toretrieve the IP address, basically as follows. In practice, a resolvermay logically reside in the operative system running in the requesterequipment, or in a specific node in the access network.

In operation, the resolver 112 may cache IP address information onearlier accessed domain names, but if the resolver does not recognisethe domain name at all, it will query the DNS tree at successive levels,one at a time. Thus, in a step 1:2, the resolver 112 may initially querythe root server at the first level 102 regarding the last field in thedomain name, e.g. “.se ?”, if not known already. The root server thenresponds by pointing to the corresponding server in the next level 104.When querying the “.se” server at level 104 in a following step 1:3regarding the next field in the domain name, e.g. “z.se?”, it willrespond by pointing to the corresponding server in the next level 106which is then accessed in step 1:4, and so forth. When the last serveris reached finally providing the IP address associated with the completedomain name, the resolver delivers the IP address back to the requester110, in a last shown step 1:5.

FIG. 2 illustrates a conventional procedure for registering a domainname for a mobile terminal A currently in connection with a mobileaccess network 200. When terminal A connects to the access network, thenetwork establishes a PDP context as described above and stores ittogether with a subscriber identity in a session database SDB 202.Terminal A receives the assigned temporary IP address from network 200in a first step 2:1, to be used for packet communication throughout itsactive period until the mobile terminal is disconnected.

A specific software in the mobile terminal for registering a domain nameissues a registration request to a domain name registration authority204, in a step 2:2, including the desired domain name together with thetemporary IP address received in step 2:1. The domain name is thenregistered with the IP address in the DNS tree 206 in a step 2:3. Anyother user 208, mobile or fixed, can then retrieve the current IPaddress of terminal A, as shown by a final step 2:4, e.g. by means of aresolver (not shown) as described above.

However, there are some problems associated with the current techniquefor providing IP addresses of client devices. In particular, the currentconcept of domain name registration in DNS servers has some seriousdrawbacks. The registration procedure and selection of domain names mustfollow certain strict rules and schemes, seriously limiting options forusers. Some amount of security is also required involving authenticationroutines, etc. There are also some other proprietary solutions foraddress handling, e.g. Skype and Outlook, but these are not alwayscompatible with other applications.

In order to keep IP addresses available by means of domain names,considerable efforts and costs must be spent on maintaining the DNS treeand its servers organized and up to date, to make the above-describedresolver process work smoothly. The update rates for individual clientdevices may also be relatively slow, resulting in out-of-dateinformation in the DNS servers for mobile users frequently changingtheir IP addresses. Further, the above-mentioned DNS and proprietarysolutions do not allow for storing additional information that may beuseful to share with others.

Further issues to deal with are that a user, or even a particularservice, may change between different client devices, and a clientdevice may furthermore have several IP addresses. It is not evident foranother user which device and/or address to use for contacting that useror service.

Generally speaking, there is no solution today for making a currentlyvalid communication address (typically the IP address) of a clientdevice easily available to any person, device or application that mightneed it for communication with the client device or any other purpose. Asolution is therefore desirable that can avoid or at least reduce theproblems and drawbacks associated with the conventional techniquedescribed above.

In this context, a “communication address” could be any network addressthat can be used directly to communicate with the client device, i.e. anetwork address such as an IP address, an MAC (Medium Access Control)address or an SIP (Session Initiation Protocol) address. IP networks mayalso use a DNS name to identify a network address.

SUMMARY

It is an object of the present invention to generally address theproblems outlined above and to provide a flexible and simple way ofmaking a currently valid communication address (typically the IPaddress) of a client device easily available, e.g., to other clientdevices. These objects and others can be obtained by a method andapparatus according to the attached independent claims.

In some aspects of the present invention, a method and an arrangementare provided that can be implemented in a client device for making itscurrently valid communication address publicly available. The clientdevice sends a freely composed connectivity key to a publicly availableconnectivity server, wherein the connectivity key is searchable by meansof web searching using a search engine. The client device also sendsconnectivity parameters associated with the connectivity key to theconnectivity server. The connectivity parameters includes at least thecommunication address of the client device, which then becomes publiclyavailable in the connectivity server by web searching of the associatedconnectivity key. The client device comprises means for executing theabove actions.

The communication address can be a network address including any of: anIP address, an MAC address, an SIP address and a DNS name. Theconnectivity parameters is updated in the connectivity server, whenevera new currently valid communication address different from the previousone is obtained for the client device, by sending the new communicationaddress to the connectivity server.

The client device may have received the connectivity key as input from auser. Alternatively, the key may have been automatically selected bydefault. The connectivity key may contain user and/or deviceidentification data that may include a user name and/or a telephonenumber. The connectivity key may further contain descriptive informationthe user has selected for characterization.

The connectivity parameters may further include capabilities of theclient device and/or application specific data. Encryption may be usedwhen sending the connectivity key and/or associated connectivityparameters to the connectivity server. If the connectivity server isdivided into a main server and a distributed separate client database towhich the connectivity parameters are sent, an alias for the clientdevice can be sent to the main server that other client devices can usefor accessing the client database and the connectivity parameters storedtherein.

In other aspects of the present invention, a method and an arrangementare provided that can be implemented in a publicly availableconnectivity server for making a currently valid communication addressof a client device publicly available, which can be used forcommunication with the client device. In the connectivity server, afreely composed connectivity key is received which is searchable bymeans of web searching using a search engine. Connectivity parametersassociated with the connectivity key are also received, including atleast the communication address of the client device. The connectivityserver then stores a connectivity record for the client device includingthe received connectivity key and associated connectivity parameters,thereby making the connectivity parameters publicly available by websearching of the associated connectivity key. The connectivity servercomprises means for executing the above actions.

The received communication address can be a network address includingany of: an IP address, an MAC address, an SIP address and a DNS name.The connectivity parameters can be updated in the connectivity record,if a new currently valid communication address obtained for the clientdevice and different from the first one, is received.

The connectivity server may be implemented in a web hotel or other largeweb site run by a known operator. The received connectivity parametersmay further include capabilities of the client device and/or applicationspecific data. Encryption can be used when receiving the connectivitykey and/or the associated connectivity parameters.

The connectivity key and connectivity parameters may be received fromthe client device, although at least the communication address can bereceived instead from a communication network responsible for assigninga network address to the client device.

The connectivity server may comprise a main server and a distributedseparate client database in which the connectivity parameters arereceived. An alias for the client device can then be received in themain server that other client devices can use for accessing the clientdatabase and the connectivity parameters stored therein.

Access to all or some of the connectivity parameters in the connectivityrecord may be restricted to specific users or groups of users by meansof encryption or login requirements.

Further features and benefits of the present invention will becomeapparent from the detailed description below.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention will now be described in more detail by means ofpreferred embodiments and with reference to the accompanying drawings,in which:

FIG. 1 is a schematic block diagram illustrating a conventionalsignalling procedure for obtaining an IP address from a DNS tree basedon a given domain name, according to the prior art.

FIG. 2 is a schematic block diagram illustrating a procedure forregistering a domain name, according to the prior art.

FIG. 3 is a flow chart illustrating a basic procedure for making acommunication address of a client device publicly available, inaccordance with the present invention.

FIG. 3 a is a schematic block diagram illustrating a signallingprocedure when the network address of a client device B is provided toanother client device A, in accordance with one embodiment.

FIG. 4 is a flow chart illustrating a procedure in a client device formaking its network address publicly available and updated, in accordancewith another embodiment.

FIG. 5 is a flow chart illustrating a procedure in a connectivity serverfor making the network address of a client device publicly available andupdated, in accordance with yet another embodiment.

FIG. 6 is a schematic block diagram illustrating a client device and aconnectivity server in which the network address of the client device ismade publicly available, in accordance with yet another embodiment.

FIG. 7 is a schematic block diagram illustrating a signalling procedurewhen the network address of a client device B is provided to anotherclient device A, in accordance with yet another embodiment.

DETAILED DESCRIPTION

Briefly described, the present solution utilises a generally availableand generic web site, in this description referred to as a “connectivityserver” which may be a single server entity or a distributed system ofplural servers. The currently valid communication address (i.e. anetwork address, typically an IP address) of any client device can bestored as a “connectivity parameter” in the connectivity server togetherwith a searchable freely composed text string and/or other informationelement valid for that client device, in this description referred to asa “connectivity key”. One or more connectivity parameters including atleast the communication address are also stored associated with theconnectivity key in the connectivity server.

In the present solution, the connectivity key is searchable by means ofconventional web searching using a search engine, thereby making theassociated communication address easily available to any person, deviceor application that might need it for communication or any otherpurpose. The communication address and its associated connectivity keyare preferably registered as a record for the client device in theconnectivity server and can be updated anytime, particularly when the IPaddress or other communication address is changed for the client device,or when its user wants to change or modify the connectivity key.

The connectivity key may be composed of any text string of optionallength and content, and a user controlling or administrating the clientdevice is free to select any piece of description or name or otherinformation to make up the connectivity key. Thus, it is not necessaryto comply with any rules or schemes when composing the connectivity key,in contrast to the above-described strict domain name registration in aDNS server. In fact, the present invention allows for enclosing anyinformation in the connectivity key that might be useful, e.g. for anylayer in the protocol stack used.

The stored communication address and its associated searchableconnectivity key should be globally available from the connectivityserver in a web page or the like. It is then possible for any person,device or application to retrieve the communication address of theclient device by making a conventional web search for terms or wordcombinations that might occur in the connectivity key, e.g. by means ofany existing public search engine such as Google or Yahoo, or aproprietary search engine.

If successful, the search result can be obtained from the search enginepreferably as a URL of the connectivity server, specifically pointing tothe web page containing the complete connectivity key and associatedcommunication address of the searched client device. This is possiblesince, according to conventional procedures, the used search engine isable to find a match between the entered search profile for the searchedclient device and the connectivity key stored for that client device inthe connectivity server.

Alternatively, an alias or the like may be stored for the client devicealong with the connectivity key in the connectivity server, whereas thecommunication address as well as any further connectivity parameters arestored in a separate client database. The alias can then be used byother client devices for obtaining the communication address from theclient database. The alias may then be a reference code or the like suchas a unique private name, and could also include a URL or otherreference pointing to the corresponding communication address in theclient database.

Using the present invention, a multitude of connectivity servers andclient databases accommodating communication addresses and associatedconnectivity keys of various client devices may be scattered around theworld. It is not at all required that the connectivity servers areorganized or mutually related in any way, in great contrast to thecentrally organized tree structure of DNS servers. Further aspects andfeatures of the present solution will be discussed in the followingexamples.

In the examples below, the term “IP address” is used throughout as it isgenerally implemented today as a communication address inpacket-switched networks. However, it should be understood that anyvalid network address serving as communication address can substitutethe IP address when applicable, e.g. an MAC address, an SIP address or aDNS name.

The term “client device” will also be used throughout this descriptionto represent any type of communication terminals used by persons toexecute voice calls and/or multimedia sessions over the Internet,including any fixed and wireless telephones and computers or the likecapable of packet-switched Internet communication. The concept of“client” and “server” is well-known, and the present invention maygenerally be useful to both client-server oriented communication andsymmetric client-client (i.e. Peer-to-Peer) communication.

As mentioned above, the term “connectivity server” in this context isnot limited to implementation in a single server entity, but may alsorepresent a logic entity that can be implemented as a distributed systemof plural servers and databases.

FIG. 3 is a flow chart illustrating steps in a connectivity server formaking the communication address of a client terminal available, inaccordance with the present solution. In a first step 30, a freelycomposed connectivity key is received from a client device which issearchable by means of web searching using a search engine, e.g.according to conventional web searching procedures such as Google orYahoo, or a proprietary search engine.

In a next step 32, a communication address currently valid for theclient device is received from the client device. Thereby, thecommunication address is associated with the connectivity key. Finally,a connectivity record is stored in the connectivity server in a step 34,including the received connectivity key and associated communicationaddress, to make the communication address publicly available by websearching of the associated connectivity key. The connectivity recordcontains connectivity parameters including at least the communicationaddress.

An embodiment for making an IP address of a client device B available toanother client device A will now be described with reference to FIG. 3a. In this case, the IP address is used as an example of a communicationaddress. Client device A is thus used for contacting client device B,the latter being registered in a connectivity server 300 basically asdescribed above. It is assumed that client device B has obtained an IPaddress for communication, e.g. by means of a PDP context or byconnecting to a fixed access point as described above. It is furtherassumed that the current IP address used by client device B is unknownto client device A and its user, and must be retrieved in order tocontact client device B. The user of device A can then use a suitablesearch engine 302 to retrieve the current IP address of client device Baccording to the following.

The client device B initially executes a registration procedure forstoring a record 304 in the connectivity server 300, containing a freelycomposed connectivity key 306 and associated connectivity parameters 308including at least the currently used IP address. This initialregistration can be divided into in a first substep 3:1 a of uploadingthe connectivity key 306 to the connectivity server 300, and a secondsubstep 3:1 b of uploading associated connectivity parameters 308. Steps3:1 a and 3:1 b can be executed basically independent of each other.

Client device B may be specifically adapted to communicate suitablemessages with the connectivity server 300 during the registrationprocedure to create the connectivity record. As indicated in the figure,the connectivity server 300 may accommodate a plurality of suchconnectivity records 304 for various other client devices as well,although this is not actually necessary.

In addition to the IP address, the connectivity parameters 308 mayoptionally include further information that could be helpful for thecommunication, such as various capabilities of client device B andapplication specific data, e.g. available codecs, link bandwidth andport number. This information may also facilitate the mobility of thedevice, user and/or ongoing session. Further, the connectivityparameters 308 and/or key 306 may be encrypted to control access theretofor security.

The connectivity key 306 can be defined in any manner, withoutlimitation as to length and content. For example, it may contain theuser's name, telephone number, as well as other user and/or deviceidentification data. It may also contain any other descriptiveinformation the user has selected, e.g., for characterization such asoccupations, titles, memberships, interests, hobbies, etc. In fact, theselection of suitable contents in the connectivity key may be used tocontrol to which extent it can be found by other users by means ofsearch engines. Also, different information in the connectivity key 306may be inserted to address different users, e.g. by means of publickeys.

The first substep 3:1 a of uploading the connectivity key 306effectively creates a database entry, i.e. the record 304, for clientdevice B in connectivity server 300. Any subsequent uploading ofassociated connectivity parameters 308 or modification of theconnectivity key 306 may refer to this entry or record 304 of clientdevice B by means of a reference code such as a user name or the like,generally serving as a register index.

Thus, after initial registration of the connectivity record 304, clientdevice B may update any parts thereof whenever needed or desired, asschematically illustrated by an optional step 3:2. In particular, the IPaddress of device B should be updated if changed for whatever reason,e.g. as exemplified in the background section. Further connectivityparameters 308 may also be changed and updated accordingly. The user oradministrator of client device B may also optionally change or modifythe connectivity key 306, if desired.

Any existing protocol can be used by client device B for uploadingupdated information in the connectivity record 304, such as thewell-known File Transfer Protocol FTP. Security may also be obtained byrequiring a user identity/password combination for uploading andupdating the connectivity parameters and/or connectivity key. Encryptionmay also be used in the communication during the registration andupdating procedures to further enhance security.

In this example, client device A now generally intends to contact clientdevice B for communication, e.g. a voice call or multimedia session,which may basically be initiated by a user or an application in thedevice A. However, the IP address of device B is unknown at device A, asmentioned above. Therefore, client device A sends a search query in anext step 3:3 to the search engine 302, using a selected search profileas input to a web search. For example, the name, telephone number and/orother identification data may constitute a search profile in the query,optionally combined with any other terms or phrases that might match thecorrect connectivity key.

Using conventional technique not necessary to describe here, searchengine 302 then performs a search and finds a match, in a step 3:4,between the input search profile and the connectivity key 306 of deviceB stored in connectivity server 300. The present solution does notexclude that search engine 302 also finds other matches (not shown)between the search profile and information on different web sites, justlike any conventional web search over the Internet might do. In otherwords, the search result does not need to be unique as the receivinguser or device may be capable of identifying the correct one, eithermanually or by means of a suitable application in the device. However,this functionality lies outside the scope of the present invention.

In response to the search query of step 3:3, search engine 302 deliversthe search result to client device A in a next step 3:5, preferablyincluding a URL of the connectivity server 300 (as well as furthersearch hits, if any). The obtained URL also points specifically to theweb page therein containing the record 304 with the matchingconnectivity key of the searched client device B and its associated IPaddress.

In an alternative embodiment, to be described in more detail later belowwith reference to FIG. 7, the IP address and other connectivityparameters may be stored in a database separate from the connectivityserver 300, where the database may actually be seen as a distributedpart of the described connectivity server function. An alias or the likefor client device B may then be stored together with the connectivitykey 306 in the connectivity server 300. In that case, the search result(i.e. the record 304) would contain the connectivity key of the searchedclient device B and its alias, which the client device A can use foraccessing that database and the connectivity parameters (including atleast the IP address) stored therein.

In a following step 3:6, client device A uses the received URL in aconventional manner to access connectivity server 300 and to retrievethe complete connectivity record 304 of client device B, where thenecessary IP address is found, according to the present embodiment. Iffurther URL's are received from search engine 302 in step 3:5 as aresult of plural hits by means of the given search profile, it should bepossible for the user and/or client device A to identify the correctone, e.g., by checking the contents of the connectivity key 306.

After extracting the received IP address, client device A can contactclient device B by means of a suitable session initiating message usingthat IP address as the destination, in a final step 3:7.

As mentioned above, the connectivity server 300 may be implemented inany web-searchable server available over the Internet to accommodateconnectivity records 304 for any number of client devices. In order toincrease the likelihood of being found by a search engine, theconnectivity server can be initially registered in the search engine, orbe implemented in a web hotel or other large web site run by awell-known operator. The connectivity server may also be fitted withdedicated (and typically standardised) so-called “search tags” tofurther assist searching. As search engines utilise caching to a greatextent to obtain rapid search results, changing or modifying theconnectivity key on an existing web page may initially cause some delayin the search.

Client device A may also make use of caching such that all foundlocations of connectivity records can be cached in device A forsubsequent use. For example, device A may cache the obtained IP addressof device B in order to make a direct contact at a later occasion. Also,device A may cache the address of the connectivity server in order toread updated connectivity parameters directly therefrom withoutperforming a web search.

FIG. 4 is a flow chart with steps executed in a client devicearrangement, in a basic procedure for making its communication addressavailable to other client devices, persons and applications, inaccordance with another embodiment. In a first step 400, the clientdevice obtains an IP address for communication, e.g. by means of a PDPcontext when switched on, or by connecting to a fixed access point asdescribed above.

A freely composed connectivity key and connectivity parameters are thenuploaded to the connectivity server, in a following step 402. Thereby, apublicly available connectivity record containing the uploadedconnectivity key and connectivity parameters can be stored for theclient device in the connectivity server. The uploaded connectivityparameters include at least the IP address obtained in step 400. In thisway, the IP address of the client device becomes available to otherclient devices, persons and applications by means of web searching, asdescribed above for FIG. 3 a.

At some point in this example, the client device obtains a new IPaddress different from the one obtained in step 400, in a next step 404,e.g. when switched on after a period of switched-off state rendering anew PDP context, or when connecting to a new access point in a networkwith fixed access points. In this embodiment, the client device isobliged to update the connectivity parameters in the connectivity serverby uploading the new IP address thereto, in a final step 406. In analternative embodiment, the currently used access network, or the homenetwork of the client device, may be responsible for updating the IPaddress in the connectivity server using a suitable communicationmechanism not necessary to describe here.

The client device may be configured with suitable means for performingthe described steps 400-406 automatically without requiring furtherinput from its user. However, the user may input a freely composedconnectivity key to the client terminal before it is uploaded to theconnectivity server in step 402. Alternatively, the client device may beconfigured to automatically select a default connectivity key afterobtaining the IP address in step 400. The default connectivity key maybe composed from the user's name, telephone number and/or otheridentification data.

A unique connectivity key may be achieved if based on existingidentification mechanisms, e.g. an e-mail or a membership identity inMSN (which is a messenger service provided by Microsoft). Further,identification data from Skype or some gaming service may also be usedfor composing the connectivity key. In general, the authenticity of theconnectivity key can be certified by forming the ID from a public key,e.g., in a private-public pair of keys used for encryption.

In the procedure described in FIG. 4, steps 400 and 402 may be somewhatmodified such that the connectivity key is first uploaded separatelybefore obtaining the IP address. Then, the connectivity parameters,including at least the obtained IP address, may be uploaded afterwardssince the connectivity key and connectivity parameters can be uploadedindependently. Different connectivity parameters may also be uploaded atdifferent occasions.

FIG. 5 is a flow chart with steps executed in a connectivity server, ina basic procedure for making the communication address of a clientdevice available to other client devices, persons and applications, inaccordance with yet another embodiment. In a first step 500, theconnectivity server receives from the client device a connectivity keyand connectivity parameters including at least the IP address of theclient device. As mentioned above, the connectivity key and connectivityparameters may be received independently at different occasions althoughbeing generally illustrated here as a single step.

In a next step 502, a publicly available connectivity record is storedfor the client device including the received connectivity key andconnectivity parameters. In this way, the IP address of the clientdevice becomes available to other client devices, persons andapplications by means of web searching, as described above for FIG. 3 a.Alternatively, the connectivity record may contain the connectivity keyand a received alias for the client device pointing to a separatedatabase where the actual connectivity parameters are stored, such thatanother user device can retrieve the IP address basically in two stagesinstead of one, which will be described further below in anotherembodiment.

The next step 504 illustrates generally that any changed or modifiedconnectivity key and/or connectivity parameters are received from theclient device. For example, as in the process described for FIG. 4, theclient device may at some point obtain a new IP address different fromthe one uploaded in step 500. Therefore, new connectivity parameters arereceived from the client device accordingly, including the changed IPaddress. Depending on the implementation, the client device may upload anew complete set of connectivity parameters (including the changed IPaddress) to replace the previously uploaded connectivity parameters, oronly the changed IP address wherein the connectivity server updates thestored connectivity parameters accordingly.

A final step 506 generally illustrates that the connectivity serverupdates the stored connectivity record with the received newconnectivity key and/or connectivity parameters, in response to thereceiving step 504.

FIG. 6 is a functional block diagram illustrating a client device 600and a connectivity server 602, according to further embodiments. Theclient device 600 and the connectivity server 602 are basicallyconfigured to participate in the procedures described above for FIGS. 3,3 a, 4 and 5. It should be noted that FIG. 6 is merely schematic and thelogic functions represented by the blocks can be implemented by means ofany suitable hardware and software.

The client device 600 comprises means 600 a for obtaining an IP addressX as communication address from a network 604 responsible for assigningIP addresses to connected devices, e.g. the current access network orthe home network of client device 600. As discussed in the previousembodiments, the IP address may be changed for various reasons, andnetwork 604 may therefore provide a new IP address X_(new) whenever thatoccurs. The client device 600 further comprises means 600 b foruploading connectivity information to the connectivity server 602,including connectivity parameters P and a connectivity key K. Theconnectivity information uploading means 600 b is also adapted to uploadat least a new IP address X_(new) whenever a new IP address has beenobtained from network 604, and any further changes or modifications ofpreviously uploaded information, when applicable.

The connectivity server 602 comprises means 602 a for receivingconnectivity information uploaded from the client device 600, such asthe shown connectivity parameters P and connectivity key K as well asany new IP address X_(new) when changed. Alternatively, as indicated bythe dashed arrow, at least the IP address may be received from network604 having assigned it to the client device, which may be the currentlyused access network or the home network of the client device.

The connectivity server 602 further comprises means 602 b for storing aconnectivity record R for the client device 600 including validconnectivity parameters and an associated connectivity key. Thereby,this information of the client device, including the IP address, becomespublicly available to other client devices, persons and applications606, typically by means of web searching using a search engine (notshown).

The above-described embodiments can be modified and varied in severalways within the scope of the present invention. The describedconnectivity server has been described as a single server entity,although it may also be implemented as a distributed system of pluralservers, as mentioned above. Moreover, the connectivity key of aspecific client terminal may reside in a server entity and theassociated connectivity parameters may be stored in a separate database.

An alternative embodiment for making a communication address of a clientdevice B available to another client device A will now be described withreference to FIG. 7. In this embodiment, a connectivity server isimplemented in a main server 700 that holds a record 702 of a clientdevice B, containing a received connectivity key 704 and a receivedalias 706 for client device B. The connectivity server is furtherimplemented in a distributed client database 708 that holds receivedconnectivity parameters 710 for client device B corresponding to thealias 706, as indicated by the dashed line. In this embodiment, otherclient devices can use the alias 706 for accessing the connectivityparameters 710 in the client database 708. As in the previous examples,the connectivity parameters 710 include at least a communicationaddress, or network address, in this case an IP address.

In a first step 7:1, client device B uploads the connectivity key 704 toconnectivity server 700. In a next step 7:2, having obtained a currentlyvalid IP address, client device B uploads its current connectivityparameters 710 to the client database 708, including at least theobtained IP address. In a following optional step 7:3, client device Balso uploads its alias 706 to the connectivity server 700 for inclusionin the record 702. Alternatively, the connectivity server may assign thealias 706 to client device B, thereby omitting step 7:3. It should benoted that steps 7:1, 7:2 and 7:3 can basically be executed in anyarbitrary sequence.

Any suitable alias 706 may be selected for client device B, depending onthe implementation, such as a private name or identity valid in theclient database 708. In this context, any suitable look-up mechanismbased on the alias 706 may be used for retrieving the correspondingconnectivity parameters 710 from the client database 708.

As in the embodiment of FIG. 3 a, client device A enters a search queryin a search engine 712 to search for client device B, in a step 7:4(similar to step 3:3). Thereafter, search engine 712 finds a match inthe connectivity key 704, as illustrated by a step 7:5 (similar to step3:4), and delivers the search result to client device A in a step 7:6(similar to step 3:5) in the form of a URL pointing to the connectivityrecord 702 of client device B in the main server 700. Client device Athen fetches the connectivity record 702 from the main server 700 usingthe received URL, in a further step 7:7, and receives the alias 706included therein. The alias may also include a URL or other referencepointing to the corresponding connectivity parameters 710 of clientdevice B in the client database 708.

In a next step 7:8, client device A accesses client database 708 andretrieves the connectivity parameters 710 therefrom, using the URL inthe received alias of B. Then finally, client device A can communicatewith client device B in a step 7:9, using the IP address as well as anyother useful information in the connectivity parameters 710.

Within the scope of the present invention, the embodiment of FIG. 7 maybe modified by introducing further look-up steps involving a series ofsimilar databases each providing a new alias for client device Bpointing to the next database, until a final database provides thenecessary connectivity parameters (i.e. at least the IP address). Thepresent solution may also involve a series of individual server unitsmaking up the connectivity server, each providing a new pointer (such asa URL) to the next one, until a final server unit provides the desiredconnectivity parameters. For example, certain connectivity parameters ofclient device B may optionally be made available for device A atspecific intermediate servers, reflecting that each server may contain adifferent type of information. One server may, e.g., handle userpresence information, while another server may handle applicationspecific information, and so forth.

In conclusion, the present invention provides a simple yet effective andflexible solution to the problem of generally providing communicationaddresses of client devices, by making them publicly available over theInternet from globally reachable web sites, i.e. the describedconnectivity server, by means of existing web search mechanisms.

In addition, other useful information embedded in the connectivityparameters and/or connectivity key can also be made available from theconnectivity server without additional functionality. For example, auser can utilize the connectivity key for exposing any kind ofinformation free of choice, as it has no limitations as to size andcontent. This is a great advantage in comparison with the traditionaldomain name registration where strictly limiting rules and schemes mustbe followed. The inventive connectivity key can further be used forcontrolling the availability by selecting its content to be matched inweb searches in a desired and controllable manner.

Moreover, any information may be inserted in the connectivity key thatcould be helpful for the communication and/or applications. Thus, it ispossible to adapt the connectivity key more or less temporarily to thetype of communication and/or applications used. This flexibility of theconnectivity key together with the flexibility of selecting differentconnectivity parameters for inclusion in the connectivity record canalso be utilised to support different kinds of session and usermobility, as well as presence services.

When implementing any of the above-described embodiments, it is possibleto restrict access to all or some of the connectivity parameters in theconnectivity record for specific users or groups of users. For example,certain connectivity parameters may be encrypted requiring a proper keyfor access, whereas other connectivity parameters may be available toanyone. In another example, the entire web page hosting the connectivityrecord may require a login procedure (involving a username/passwordcombination) for restricting access thereto.

Another advantage with the present invention compared to the domain nameregistration, is that a limitless number of such connectivity serverscan be established without requiring any coordination or organization,as opposed to the DNS tree structure.

While the invention has been described with reference to specificexemplary embodiments, the description is only intended to illustratethe inventive concept and should not be taken as limiting the scope ofthe invention. Various alternatives, modifications and equivalents maybe used without departing from the spirit of the invention, which isdefined by the appended claims.

1. A method of making a currently valid communication address of a client device publicly available, which can be used for communication with the client device, comprising the following steps, as executed in said client device: sending a freely composed connectivity key to a publicly available connectivity server, wherein said connectivity key is searchable by means of web searching using a search engine, and sending connectivity parameters associated with the connectivity key to the connectivity server, said connectivity parameters including at least the communication address of the client device, which then becomes publicly available in the connectivity server by web searching of the associated connectivity key using said search engine to obtain a search result as a URL of the connectivity server, specifically pointing to a web page containing the connectivity key and associated communication address of the searched client device, wherein the communication address of the client device can be retrieved by means of said URL of the connectivity server.
 2. A method according to claim 1, wherein said communication address is a network address including any of: an IP address, an MAC address, an SIP address and a DNS name.
 3. A method according to claim 1, further comprising the step of updating said connectivity parameters in the connectivity server if a new currently valid communication address different from the previous one is obtained for the client device, by sending the new communication address to the connectivity server.
 4. A method according to claim 1, wherein said connectivity key has been received as input from a user.
 5. A method according to claim 1, wherein said connectivity key has been automatically selected by default.
 6. A method according to claim 1, wherein said connectivity key contains user and/or device identification data.
 7. A method according to claim 6, wherein the identification data includes a user name and/or a telephone number.
 8. A method according to claim 6 wherein said connectivity key further contains descriptive information the user has selected for characterization.
 9. A method according to claim 1, wherein said connectivity parameters further includes capabilities of the client device and/or application specific data.
 10. A method according to claim 1, wherein encryption is used when sending the connectivity key and/or associated connectivity parameters to the connectivity server.
 11. A method according to claim 1, wherein the connectivity server comprises a main server and a distributed separate client database to which said connectivity parameters are sent, and wherein an alias for said client device is sent to the main server that other client devices can use for accessing said client database and the connectivity parameters stored therein.
 12. An arrangement in a client device for making a currently valid communication address of the client device publicly available, which can be used for communication with the client device, comprising: means for sending a freely composed connectivity key to a publicly available connectivity server, wherein said connectivity key is searchable by means of web searching using a search engine, and means for sending connectivity parameters associated with the connectivity key to the connectivity server, said connectivity parameters including at least the communication address of the client device, which then becomes publicly available in the connectivity server by web searching of the associated connectivity key using said search engine to obtain a search result as a URL of the connectivity server, specifically pointing to a web page containing the connectivity key and associated communication address of the searched client device, wherein the communication address of the client device can be retrieved by means of said URL of the connectivity server.
 13. An arrangement according to claim 12, wherein said communication address is a network address including any of: an IP address, an MAC address, an SIP address and a DNS name.
 14. An arrangement according to claim 12, further comprising means for updating said connectivity parameters in the connectivity server if a new currently valid communication address different from the previous one is obtained for the client device, by sending the new communication address to the connectivity server.
 15. An arrangement according to claim 12, further comprising means for receiving said connectivity key as input from a user.
 16. An arrangement according to claim 12, further comprising means for automatically selecting said connectivity key by default.
 17. An arrangement according to claim 12, wherein said connectivity key contains user and/or device identification data.
 18. An arrangement according to claim 17, wherein the identification data includes a user name and/or a telephone number.
 19. An arrangement according to claim 17, wherein said connectivity key further contains descriptive information the user has selected for characterization.
 20. An arrangement according to claim 12, wherein said connectivity parameters further includes capabilities of the client device and/or application specific data.
 21. An arrangement according to claim 12, further comprising means for using encryption when sending the connectivity key and/or the associated connectivity parameters to the connectivity server.
 22. An arrangement according to claim 12, wherein the connectivity server comprises a main server and a distributed separate client database to which said connectivity parameters are sent, further comprising means for sending an alias for said client device to the main server that other client devices can use for accessing said client database and the connectivity parameters stored therein.
 23. A method of making a currently valid communication address of a client device publicly available, which can be used for communication with the client device, comprising the following steps, as executed in a publicly available connectivity server: receiving a freely composed connectivity key which is searchable by means of web searching using a search engine, receiving connectivity parameters associated with the connectivity key, said connectivity parameters including at least the communication address of the client device, and storing a connectivity record for the client device including the received connectivity key and associated connectivity parameters, thereby making the connectivity parameters publicly available by web searching of the associated connectivity key using said search engine to obtain a search result as a URL of the connectivity server, specifically pointing to a web page containing the connectivity key and associated communication address of the searched client device, wherein the communication address of the client device can be retrieved by means of said URL of the connectivity server.
 24. A method according to claim 23, wherein the received communication address is a network address including any of: an IP address, an MAC address, an SIP address and a DNS name.
 25. A method according to claim 23, comprising the further step of updating said connectivity parameters in the connectivity record, if a new currently valid communication address obtained for the client device and different from the first one, is received.
 26. A method according to claim 23, wherein the connectivity server is implemented in a web hotel or other large web site run by a known operator.
 27. A method according to claim 23, wherein the received connectivity parameters further includes capabilities of the client device and/or application specific data.
 28. A method according to claim 23, wherein encryption is used when receiving the connectivity key and/or the associated connectivity parameters.
 29. A method according to claim 23, wherein said connectivity key and connectivity parameters are received from the client device.
 30. A method according to claim 23, wherein at least said communication address is received from a communication network responsible for assigning a network address to the client device.
 31. A method according to claim 23, wherein the connectivity server comprises a main server and a distributed separate client database in which said connectivity parameters are received, and wherein an alias for said client device is received in the main server that other client devices can use for accessing said client database and the connectivity parameters stored therein.
 32. A method according to claim 23, wherein access to all or some of the connectivity parameters in the connectivity record is restricted to specific users or groups of users by means of encryption or login requirements.
 33. An arrangement in a publicly available connectivity server for making a currently valid communication address of a client device publicly available, which can be used for communication with the client device, comprising: means for receiving a freely composed connectivity key which is searchable by means of web searching using a search engine, means for receiving connectivity parameters associated with the connectivity key, said connectivity parameters including at least the communication address of the client device, and means for storing a connectivity record for the client device including the received connectivity key and associated connectivity parameters, thereby making the connectivity parameters publicly available by web searching of the associated connectivity key using said search engine to obtain a search result as a URL of the connectivity server, specifically pointing to a web page containing the connectivity key and associated communication address of the searched client device, wherein the communication address of the client device can be retrieved by means of said URL of the connectivity server.
 34. An arrangement according to claim 33, wherein the received communication address is a network address including any of: an IP address, an MAC address, an SIP address and a DNS name.
 35. An arrangement according to claim 33, further comprising means for updating said connectivity parameters in the connectivity record, if a new currently valid communication address obtained for the client device and different from the first one, is received.
 36. An arrangement according to claim 33, wherein the connectivity server is implemented in a web hotel or other large web site run by a known operator.
 37. An arrangement according to claim 33, wherein the received connectivity parameters further includes capabilities of the client device and/or application specific data.
 38. An arrangement according to claim 33, further comprising means for using encryption when receiving the connectivity key and/or the associated connectivity parameters.
 39. An arrangement according to claim 33, wherein said receiving means are adapted to receive the connectivity key and associated connectivity parameters from the client device.
 40. An arrangement according to claim 33, wherein said connectivity parameters receiving means is adapted to receive at least said communication address from a communication network responsible for assigning a network address to the client device.
 41. An arrangement according to claim 33, wherein access to all or some of the connectivity parameters in the connectivity record is restricted to specific users or groups of users by means of encryption or login requirements. 